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MARKED-UP SPECIFICATION 



Title of the invention 

Devices for retrieving and delivering a multimedia message, 
5 and methods for the same 



Cross Reference to Related Applications 

This application is based on and hereby claims priority to 
PCT Application No. PCT/EP03/12439 filed on November 6, 2003, 
10 the contents of which are hereby incorporated by reference. 

Field of the invention 

The invention relates to retrieving and delivering of 
multimedia messages using the Session Initiation Protocol. 

15 

Discussion of background art 

Multimedia Messaging Service MMS has in its present form been 
defined in standard 3GPP TS 23.140 "3rd Generation 
Partnership Project; Technical Specification Group Terminals; 

20 Multimedia Messaging Service (MMS); Functional description; 
Stage 2 (Release 6)". The architecture of the networks 
involved as well as functions of different modules, 
especially the MMS User Agent and the MMS Relay/Server (below 
referred to as MMS Server) , are described in more detail 

25 therein. 

Notifications of incoming MMS messages are delivered from the 
MMS server to the MMS User Agent by using WAP push. The MMS 
User Agent sends a WAP or HTTP GET in order to make the MMS 
30 server send an MMS message. 
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The transfer of Multimedia Messaging Services MMS messages is 
usually performed using the Wireless Application Protocol WAP 
or Hypertext Transport Protocol HTTP. Retrieval of an MMS 
5 message is then performed by sending a WAP or HTTP GET 
request, respectively. 

Messaging services implemented for the IP Multimedia core 
network Subsystem IMS network are currently under discussion 

10 in the 3GPP. The IMS messaging services comprise messaging 
types immediate messaging, deferred delivery messaging, and 
session-based messaging. In immediate messaging, a message is 
delivered immediately from one user to another, whereas in 
deferred messaging it is delivered as soon as the recipient 

15 becomes available. In session-based messaging, a session has 
to be set up before any other communication can take place. 

In the IMS network, the Session Initiation Protocol SIP is 
used for creating, modifying, and terminating sessions with 

20 one or more participants. Two methods defined in the SIP are 
SUBSCRIBE and NOTIFY. SUBSCRIBE is used by a subscriber 
terminal to subscribe to event packages at proxies or 
servers. Whenever an event belonging to the subscribed event 
package is triggered, the terminal is informed by using the 

25 SIP method NOTIFY. 

It may be commercially of vital importance to be able to 
retrieve MMS messages directly from within IMS. This has, 
nevertheless and in spite of hard work, been impossible until 
30 . now. 
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Summary of the invention 

It is an objcctivc one possible object of the invention to 
bring about new features to the Session Initiation Protocol 
SIP with which Multimedia Messaging Services MMS messages can 
5 be retrieved or delivered using the SIP protocol only, J £ke 
object of retrieving MMS mcooagco uoing the SIP protocol can 
be achieved with a method according to the independent claim 
-3t7 — or by using a terminal according to the independent claim 
— The object of delivering MMS messages uoing the SIP 

10 protocol can be achieved with a method according to the 

independent claim 5, — or by uoing an MMS ocrvcr according to 
the independent claim 8. — Dependent patent claimo dcocribc 
variouo advantagcouo cmbodimcnto of the invention. 
Advantages of the invention 

15 The inventors propose devices and methods according to fcke 
invention enable using the SIP as single transport protocol 
for retrieving and delivering MMS messages. In this manner, 
the terminals do not need to have other protocols than SIP 
supported by their protocol stack, thereby helping to reduce 

20 manufacturing cost of the terminals. Further, because there 
are less protocols needed in the protocol stack, the 
probability for errors in the software is reduced, therefore 
also shortening testing period of the devices, resulting in a 
shorter time-to-market . 

25 

Short Brief description of the drawings 

In the following, the preferred embodiments of the invention 
are described in more detail with reference to the 
accompanying drawings 1 to 4, of which: 

30 

Figure 1 shows a mobile network comprising also IP 

Multimedia core network Subsystem; 



» 
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Figure 2 



shows the structure of a new SIP message used for 



retrieving or delivering an MMS message; 



5 Figures 3a and 3b show the structure of two different SIP 



Detailed description of the invention Preferred Embodiments 

Figure 1 shows a terminal 101 within a Radio Access Network 
15 RAN 11 of a mobile network 12. The RAN 11 comprises a 

plurality of Base Stations BS 103 controlled by a Radio 
Network Controller RNC 105, the terminal 101 communicating 
with the mobile network 12 wirelessly via a BS 103. 
Typically, one mobile network 12 comprises a plurality of RNC 
20 105, but for simplicity Figure 1 shows only one such RNC 105. 

A terminal 101 has communication moano a transceiver 165, 
preferably those as commonly used for radio communications, 
and all related moano accessories for enabling a successful 

25 communication with the mobile network 12. Within the terminal 
101, the processing unit 170 uses the communication means 165 
in order to transmit and receive data. Both data to be 
transmitted and data received are filtered via the protocol 
stack 175 before any further operations are performed on 

30 them. The terminal 101 may have a plurality of applications 
stored in its memory. These applications include also an MMS 
User Agent 180 which takes care of all MMS specific 



messages; and 



10 



Figure 4 



shows messaging (41) used for subscribing an 
event package, messaging (43) used for notifying 
a terminal upon receipt of an MMS message, and 
messaging (45) used for downloading an MMS 
message to a subscriber terminal. 
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interactions between the home network 14 and the terminal 
101. The applications are run in the processing unit 170 and 
they use data obtained through the communication means 165 
and filtered through the protocol stack 175. 

5 

For packet traffic, the mobile network 12 comprises a Serving 
GPRS Support Node SGSN 107 and Gateway GPRS Support Node GGSN 
109. The terminal 101 obtains an IP address which is reserved 
up to the GGSN 109. The traffic between the terminal 101 and 

10 the GGSN 109 goes then on the GPRS Tunneling Protocol GTP 

protocol layer through the SGSN . 107 and the RAN 11, wherein 
there are further specific radio interface layer protocols 
facilitating resource-efficient data transport over the air 
interface. As the skilled person appreciates, a more detailed 

15 description of the related protocols can be found in any of 
the various standards defining these mechanisms. 

The terminal 101 may be roaming under, mobile network 12 even 
though its home network 14 were elsewhere. The transmission 
20 of packet data is then performed either directly between the 

terminal 101 and its home network 14 or via any other 

t 

network, especially the Internet 13. 

The home network 14 comprises a Home Service Server HSS 115 
25 which includes subscriber data and knows under which mobile 
network 12 the terminal 101 is roaming. A Serving Call State 
Control Function S-CSCF 113 is located in the home network 14 
of the terminal 101. If the terminal 101 is roaming under 
another mobile network 12, then the S-CSCF 113 of home 
30 network 14 is used via a Proxy Call State Control Function P- 
CSCF 111. The P-CSCF 111 includes data about services 
subscribed for the terminal 101; this data has been 
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transmitted from the S-CSCF 113 to the P-CSCF 111 as a 
response to a query sent by the P-CSCF 111. 

In mobile telecommunication systems, such as in GSM and UMTS, 
5 the SIP is used for the IP multimedia core network Subsystem 
IMS. The IMS includes P-CSCF 111, S-CSCF 113, and servers 
providing some of the services. Especially for MMS messages, 
MMS server 130 is used as the server providing all MMS 
related services. 

10 

The MMS server 130 comprises communication means 185 for 
communication between terminals 101, with other MMS servers 
130, and with servers in the Internet 13. The processing unit 
190 of the MMS server 130 uses the communication 

15 mcans transciever 185 as well as the protocol stack 195. The 

protocol stack 195 comprises IMS protocols enabling provision 
of different services. The protocol stack 195 may further 
comprise an MMS specific part. The MMS server 130 is running 
an MMS application 196 which takes care of registering event 

20 packet subscriptions, notifying subscriber terminals of 

received MMS messages belonging to a subscribed event packet, 
and delivering MMS retrievals in response to receiving MMS 
retrieval requests . 

25 Figure 2 shows the structure of the MMS part of the new SIP 
messages 20 used for subscribing an event package, or 
retrieving or delivering an MMS message. The SIP message 20 
comprises fields 21 (X-Mms _Message-Type ) , 22 (X-Mms- 
Transaction ID), 23 (X-Mms-MMS Version), 24 (To), and 25 

30 (From) . These fields 21 to 25 are usually carried in the 
header of the SIP message 20. 
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Figures 3a and 3b show the structures of two different SIP 
messages 20. The SIP message 20a used for carrying MMS 
subscription request message M401 is shown in Figure 3a and 
comprises in its field 21 identifier "m-sreq" and further in 
5 field 36A flag "yes". The SIP message 20b used for carrying 
MMS subscription response message M403 is shown in Figure 3b 
and comprises in field 21 identifier "m-sref", and further an 
acknowledgement "OK" in field 36B. 

10 The skilled person appreciates that the examples shown in 
Figures 2, 3a, and 3b are schematic of their nature. More 
detailed description for all header and message formats can 
be found in IETF specifications RFC 3261 and 3265. RFC 3261 
introduces the SIP and RFC 3265 introduces the SIP-Specific 

15 Event Notification. Both of these specifications define also 
the SIP methods later referred to in this description. 

Dashed box 41 in Figure 4 shows how an event package is 
subscribed. The MMS User Agent 180 requests by sending MMS 

20 subscription request M401 to the MMS Server 130 that the MMS 
Server 130 uses a SIP method NOTIFY for sending MMS 
notifications. MMS subscription request M401 has a form of 
message 20b shown in Figure 3b, and it is sent by the 
terminal 101 as soon as it has been switched on for the first 

25 time and has network coverage. The MMS subscription request 
M401 is acknowledged by the MMS Server 130 with an MMS 
subscription response M403. 

Dashed box 43 shows how the terminal 101 is informed upon 
30 receipt of MMS message N404. As soon as the MMS Server 130 
receives the MMS message N4 04 which belongs to a subscribed 
event package, it sends MMS notification M405 to the MMS User 
Agent 180 informing it that the MMS message N404 has arrived 
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at the MMS Server 130. The MMS User agent 180 responds to MMS 
notification M405 with MMS notification response M407. 



Dashed box 45 shows how the MMS message N404 received by the 
5 MMS Server 130 can be downloaded to the terminal 101. In 

response to the MMS notification M405, the MMS User Agent 180 
can decide to download the MMS message N404 by sending an MMS 
message retrieval request M409 to the MMS Server 130. MMS 
message retrieval request M409 is a SIP FETCH message. 

io 

In response to receiving MMS message retrieval request M409 
the MMS Server 130 sends MMS message retrieval M411 to the 
MMS Server 130. MMS message retrieval M411 includes the 
contents of MMS message N404. 

15 

The MMS User Agent 180 acknowledges the receipt of the MMS 
message retrieval M411 by returning MMS message retrieval 
acknowledgement M413. In response to receiving MMS message 
retrieval acknowledgment M413 the MMS Server 130 responds 
20 with acknowledgement M417. 

MMS subscription request M401; MMS subscription response 
M403; MMS notification M405; MMS notification response M407; 
MMS message retrieval request M409; MMS message retrieval 

25 M411; and MMS message retrieval acknowledgement M413 all have 
structures similar to those shown in Figures 3a and 3b except 
that the value in field 21 is changed accordingly to identify 
the kind of the message. The structure of these messages is 
otherwise as defined in 3GPP, TS 23.140 already referred 

30 .above. 
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Messages M401 to M417 communicated between the terminal 101 
and the MMS Server 130 are routed via BS 103, SGSN 107, GGSN 
109, P-CSCF 111, and S-CSCF 113, if necessary. 

5 For MMS subscription request M401 the header field "event" is 
set to value "mms" identifying the purpose of the MMS 
subscription request M401, i.e. that the MMS User Agent 180 
requests the MMS Server 130 to use the SIP method notify for 
sending MMS notifications M405. 

10 

As in MMS subscription request M401, also in MMS notification 
M405 the header field "event" is set to value "mms", this 
informing the terminal 103 about the incoming MMS 
notification in MMS notification M405. 

15 

Messages M401 to M417 comprise SIP-specific heade'r fields and 
MMS level header fields. 

The MMS subscription request M401 is sent using the SIP 
20 method SUBSCRIBE. The MMS subscription request M401 comprises 
an event identifier defining that the SIP method NOTIFY is to 
be used for sending MMS notifications M405. After receiving 
an MMS notification M405, the terminal 101 generates and 
sends an MMS message retrieval request M409 

25 

In the first embodiment, the MMS level header fields are 
added to the header fields in the messages M401 to M417. 
Then the S-CSCF 113 analyses the SIP headers of each incoming 
message. If any MMS-specific headers is detected, for example 
30 by detecting a keyword "X-Mms-" in the fields, the S-CSCF 113 
routes the message to the MMS Server 130. Similarly, all SIP 
messages received by the terminal 101 are checked for any 
MMS-specific headers, and if any is found, the message is 



2003P16960WO 

10 

passed to the MMS User Agent 180. An advantage of such a 
header structure is that all both SIP and MMS headers have a 
similar format and coding. In particular for a SIP-only 
terminal this reduces the implementation effort since a 
5 single coding scheme can be applied to the SIP protocol stack 
as well as to the application level. 

In the second embodiment, the header fields of the SIP 
messages comprise SIP-specif ic header fields only. In this 

10 approach the MMS information is an attachment of the SIP 

message. The S-CSCF 113 checks if the attachment is an MMS 
message. If in the header field "Content-Type:" a keyword 
"application/vnd. wap .mms-message" is detected, this is most 
probably the case, and the message is then routed to the MMS 

15 Server 130. The header field "Content-Type:" of SIP messages 
received by the terminal 101 is in the same manner checked. 
If the header field comprises "application/vnd. wap. mms- 
message". The SIP message is passed to the MMS User Agent 
180. An advantage of such a header structure and encoding is 

20 that in this manner a better compatibility with currently 
existing MMS systems can be achieved. In particular, 
terminals comprising a current MMS client software which is 
only ported to a SIP protocol stack, no extra encoder or 
decoder for processing the messages M401 to M417 is needed 

25 therefore making it easier to implement a terminal 101 
supporting MMS functionalities. 

Some of the acknowledgement messages, i.e. MMS subscription 
response M403, MMS notification response M407, and MMS 
30 message retrieval M411 are 200 OK messages. Further, they 

comprise relevant MMS headers, and MMS message retrieval M411 
further includes the MMS message N404 received by the MMS 
Server 130. All these acknowledgement messages may either 
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comprise SIP-specific header fields or in addition to the SIP 
-specific header fields also some MMS-specific header fields. 
In the former case the other data necessary is embedded in 
the payload. 

The other acknowledgement messages, i.e. MMS message 
retrieval acknowledgement M413 and acknowledgement M417 are 
200 OK messages too. Contrary to other 200 OK messages 
described above, they comprise no MMS-specific information. 

The invention has been described in detail with particular 
reference to preferred embodiments thereof and examples, but 
it will be understood that variations and modifications can 
be effected within the spirit and scope of the invention 
covered by the claims which may include the phrase "at least 
one of A, B and C" as an alternative expression that means 
one or more of A, B and C may be used, contrary to the 
holding in Superguide v. DIRECTV, 69 USPQ2d 1865 (Fed. Cir. 
2004) . 
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List of uaed reference numerals 

II Radio Access Network RAN 
5 12 mobile network 

14 home network 

101 terminal 

103 Base Station BS 

105 Radio Network Controller RNC 

10 107 Serving GPRS Support Node SGSN 

10 9 Catcway CPRS Support Node GGSN 

III Proxy - Call State Control Function P - CSCF 
113 Serving Call State Control Function S - CSCF 
115 Home Service Server HSS 

15 130 MMS Server 

165 communication means 

170 processing unit 

175 protocol stack 

1 8 0 MMS User Agent 

20 185 communication means 

190 processing unit 

195 protocol stack 

196 MMS application 

25 



